Digital Mapping System

ABSTRACT

Various methods, systems, and apparatus for implementing aspects of a digital mapping system are disclosed. One such method includes sending a location request from a client-side computing device to a map tile server, receiving a set of map tiles in response to the location request, assembling said received map tiles into a tile grid, aligning the tile grid relative to a clipping shape, and displaying the result as a map image. One apparatus according to aspects of the present invention includes means for sending a location request from a client-side computing device to a map tile server, means for receiving a set of map tiles in response to the location request, means for assembling said received map tiles into a tile grid, means for aligning the tile grid relative to a clipping shape, and means for displaying the result as a map image. Such an apparatus may further include direction control or zoom control objects as interactive overlays on the displayed map image, and may also include route or location overlays on the map image.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.11/567,054 filed on Dec. 5, 2006, which is a continuation of U.S. patentapplication Ser. No. 11/051,534, filed on Feb. 5, 2005 and entitled“Digital Mapping System”, which claims priority of U.S. ProvisionalPatent Application No. 60/567,946, filed May 3, 2004, and U.S.Provisional Patent Application No. 60/555,501, filed Mar. 23, 2004,where the entirety of each of said applications is hereby incorporatedherein by reference.

BACKGROUND

1. Field of the Invention

Implementations consistent with the principles of the invention relategenerally to mapping systems, and more specifically, to mapping systemsin a digital environment.

2. Description of Related Art

Computerized mapping systems have been developed for facilitating travelplanning. For example, travel-planning Internet websites arecommercially available and well-known. Such websites typically permit auser to input a query with a requested location so that a map associatedwith the requested location may be provided to the user. Also,well-known websites allow the user to enter a start point and an endpoint for travel, which are then used to calculate and provide traveldirections to the user.

By way of background for the detailed discussion of certain aspects ofthe present invention that will follow, FIGS. 1-4 depict certain aspectsof an exemplary conventional digital mapping system. FIG. 1 illustratesa web browser user interface 100 that displays a map request entry webpage 105. As shown, a user has entered a desired location of 353 MainSt., Billings, Mont. 45619. After entering the desired location to bemapped, as shown in FIG. 1, the user then requests a map (typically froma remote server) by selecting a “Request Map” button 110. A map image isthen typically generated at the remote server, transmitted to the user'scomputing device, and eventually displayed on the web browser userinterface 100 in a map display web page.

FIG. 2 illustrates an exemplary map display web page 200 on a webbrowser user interface 100. Here, a map display webpage 200 displays theresults of the map request from FIG. 1. The displayed informationgenerally consists of a map image 205, which depicts the requestedlocation and surrounding area. As shown in FIG. 2, the requestedlocation is identified on the map image 205 by an address icon 208, andthe address icon 208 is typically located in the center of map image205. The requested location and address icon 208 may also be displayedon a map legend window 210 within map display web page 200. The addressicon 208 is typically a simple two-dimensional image which, if displayedwithin map image 205 in close proximity with other such icons, maycreate visual clutter and confuse or mislead the user as to where eachicon is actually pointing within map image 205.

The map webpage 200 may also display buttons or other user interfaceobjects that may be selected to control the manner in which map image205 is displayed. For example, as shown in FIG. 2, zoom control objects220 are generally provided to allow the user to “zoom in” or “zoom out”and thereby affect the displayed scale of map image 205 accordingly,typically while retaining the desired location marked by address icon208 at the center of the image. Also, direction buttons or other similaruser interface objects, such as “down arrow” direction button 215, maybe provided to allow the user to “pan” the image, such as by displayingmore of the map information that was previously hidden because it wasbeyond the “southern” boundary of map image 205, while shifting andhiding a corresponding portion of the previously displayed “northern”portion of the map information. As shown in FIG. 2, such image controlobjects are conventionally displayed outside the boundary area of themap image 205, reducing the amount of space available for the map image205 within the map display web page 200.

Typically, when image control objects (such as zoom control objects 200or direction button 215 shown in FIG. 2) are selected, an HTTP requestis transmitted to a server, which then transmits a new image containingthe new map information to be displayed at the selected zoom level.

Specifically, in an exemplary system, as shown in FIG. 3, a web browser300 sends an HTTP request containing location information for arequested map image to a web server 305. The HTTP request may consist oflocation data received via a web browser user interface 100 through adata entry web page 105, as illustrated in FIG. 1. For example, as shownif FIG. 1 and described earlier, a user may enter the following desiredlocation to be mapped: 353 Main St., Billings, Mont., 45619. The userthen requests the directions by selecting a “Request Map” button 110,and this selection event eventually causes the HTTP Request shown inFIG. 3 to be transmitted (directly or indirectly) from web browser 300to web server 305. In response to the HTTP request, the web server 305sends a database query (“DB Query”) to a map vectors database 310. Themap vectors database 310 typically determines the corresponding vectorsfor the desired location data and transmits these vectors to the webserver 305. The web server 305 then typically generates a bitmap imageof the desired map using the received vectors, and converts the bitmapinto an image format that is supported by the web browser 300 (e.g.,GIF, PNG, JPEG, and the like.). The web server 305 then transmits theimage to the web browser 300, generally embedding it within HypertextMarkup Language (HTML) code. The map image is then displayed to the uservia the web browser user interface 100 (as shown in FIG. 2 and describedearlier). Thus, when the user requests a new map view, e.g., by enteringa postal address, or by clicking a navigation link next to a current mapview, the web browser 300 sends to a web server 305 a request indicatingthe boundaries of the new map view. The web server 305 in turn extractsthe corresponding vector-based map data from a database, and draws abitmap image of the map. The web server 305 then converts the bitmapimage to an image format supported by the web browser 300 and returnsthe image, sometimes embedded in HTML, to the web browser 300 fordisplay to the user. Commercial implementations of such systems includeAOL's MapQuest (http://www.mapquest.com), Yahoo's Telcontar-based“SmartView” maps (http://maps.yahoo.com), and Microsoft's MapPoint.netsuite (e.g., http://maps.msn.com).

FIG. 4 illustrates a second exemplary system used for providing map datato a web browser. As shown in FIG. 4, a web browser 300 transmits anHTTP request to a web server 305 in the same manner that was describedearlier with respect to FIG. 3. Upon receiving HTTP request from webbrowser 300, the web server 305 shown in FIG. 4 transmits a databasequery (“DB Query”) containing the requested location data to a mapraster database 410. The map raster database 410 extracts theappropriate image based on the database query from among a largerpre-rendered map image. The requested image is then transmitted to theweb server 305, which then transmits the image to the web browser 300 asdescribed earlier. Thus, in a digital mapping system as shown in FIG. 4,the steps of extracting vectors and drawing a map image are replaced bysimply extracting the appropriate part of a larger, pre-rendered image.Commercial implementations of such systems include Britain's MultiMaps(http://multimaps.com) and Australia's WhereIs(http://www.whereis.com.au). It should also be noted that such systemstypically generate the map images from the same vector-based files thatwould also be used to generate printed versions of such maps.

Certain providers of digital mapping web sites have observed that someof the above problems may be overcome by transmitting a number ofsmaller images (known as “tiles”) from the web server 305 to the webbrowser 300. These smaller tiles can then be assembled by the webbrowser 300 into a larger image. For example Microsoft's TerraServer USAsite (at http://terraserver.homeadvisor.msn.com/) currently uses atiling approach for displaying satellite images.

BRIEF SUMMARY

Various methods, systems, and apparatus for implementing aspects of adigital mapping system are disclosed. One such method includes sending alocation request from a client-side computing device to a map tileserver, receiving a set of map tiles in response to the locationrequest, assembling said received map tiles into a tile grid, aligningthe tile grid relative to a clipping shape, and displaying the result asa map image. One apparatus according to aspects of the present inventionincludes means for sending a location request from a client-sidecomputing device to a map tile server, means for receiving a set of maptiles in response to the location request, means for assembling saidreceived map tiles into a tile grid, means for aligning the tile gridrelative to a clipping shape, and means for displaying the result as amap image. Such an apparatus may further include direction control orzoom control objects as interactive overlays on the displayed map image,and may also include route or location overlays on the map tile image.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute apart of this specification, illustrate various embodiments. In thedrawings,

FIG. 1 illustrates an exemplary web browser displaying a map requestentry web page.

FIG. 2 illustrates an exemplary map display on a web browser.

FIG. 3 illustrates an exemplary conventional vector-based digitalmapping system architecture.

FIG. 4 illustrates an exemplary conventional raster-based digitalmapping system architecture.

FIG. 5 illustrates a distributed network system according to aspects ofthe present invention.

FIG. 6 is an exemplary block diagram of a client-side or server-sidecomputing device according to aspects of the present invention.

FIG. 7 illustrates an exemplary tile-based digital mapping systemarchitecture according to aspects of the present invention.

FIG. 8 illustrates an exemplary combined map request entry and mapdisplay web page according to aspects of the present invention.

FIG. 9 illustrates an exemplary server-side architecture according toaspects of the present invention.

FIG. 10 illustrates further aspects of an exemplary server-sidearchitecture consistent with principles of the present invention.

FIG. 11 illustrates an exemplary map image tile grid and clippingrectangle according to aspects of the present invention.

FIG. 12 depicts a resulting map image after comparing an exemplary tilegrid with a clipping rectangle according to aspects of the presentinvention.

FIG. 13 illustrates the underlying tile grid coordinates and clippingshape corresponding to an exemplary set of displayed images according toaspects of the present invention.

FIG. 14 illustrates a flowchart of one embodiment for transmitting maptiles to a web browser and caching the tiles locally at the web browseraccording to aspects of the present invention.

FIG. 15 illustrates a flowchart that may be used according to oneembodiment for displaying driving directions as an overlay onto a mapimage.

FIG. 16 depicts a flow chart for performing a map image panningoperation according to one embodiment of the present invention.

FIGS. 17 through 21 illustrate an exemplary process of panning west by ⅓of the clipping shape's width according to one embodiment of the presentinvention.

FIG. 22 depicts an exemplary flow chart for implementing a zoomingoperation according to one embodiment of the present invention.

FIG. 23 depicts an exemplary flow chart for overlaying a set of locationmarkers onto a map image according to one embodiment of the presentinvention.

FIG. 24 depicts an exemplary map display web page with multiple overlaidlocation markers according to aspects of the present invention.

FIG. 25 depicts exemplary details of a location marker according toaspects of the present invention.

FIG. 26A depicts exemplary details of an information window according toaspects of the present invention.

FIG. 26B depicts additional exemplary details of an information windowaccording to aspects of the present invention.

FIG. 27 depicts an exemplary map display web page with an overlaiddriving direction route trace according to aspects of the presentinvention.

FIG. 28 depicts an exemplary map display web page with an overlaid areaboundary trace according to aspects of the present invention.

FIG. 29 depicts an exemplary flow chart for overlaying a set ofinformation windows onto a map image according to one embodiment of thepresent invention.

FIG. 30 depicts an exemplary flow chart for resizing a map image displaywindow according to one embodiment of the present invention.

FIG. 31 depicts an exemplary set of map image tiles of differentresolutions for high-quality printing of map images according to oneembodiment of the present invention.

DETAILED DESCRIPTION

Various aspects of the disclosure are described herein in the context ofan apparatus, system, and method for obtaining and displaying mappinginformation. Those of ordinary skill in the art will realize that thefollowing description is illustrative only and not in any way limiting.Other aspects will readily suggest themselves to such persons having thebenefit of this disclosure.

For example, any number of computer programming languages, such as theJava language, JavaScript, Java Applet technology, C, C++, Perl, Pascal,Smalltalk, FORTRAN, assembly language, HTML (i.e., Hypertext MarkupLanguage), DHTML (i.e., Dynamic Hypertext Markup Language), XML (i.e.,eXtensible Markup Language), XLS (i.e., eXtensible Style Language), SVG(i.e., Scalable Vector Graphics), VML (i.e., Vector Markup Language),Macromedia's Flash technology, and the like, may be used to implementaspects of the present invention. Further, various programmingapproaches such as procedural, object-oriented or artificialintelligence techniques may be employed, depending on the requirementsof each particular implementation.

The same reference numbers will be used throughout the drawings anddescription in this document to refer to the same or like parts.Further, certain figures in this specification are flow chartsillustrating methods and systems. It will be understood that each blockof these flow charts, and combinations of blocks in these flow charts,may be implemented by computer program instructions. These computerprogram instructions may be loaded onto a computer or other programmableapparatus to produce a machine, such that the instructions which executeon the computer or other programmable apparatus create structures forimplementing the functions specified in the flow chart block or blocks.These computer program instructions may also be stored in acomputer-readable memory that can direct a computer or otherprogrammable apparatus to function in a particular manner, such that theinstructions stored in the computer-readable memory produce an articleof manufacture including instruction structures which implement thefunction specified in the flow chart block or blocks. The computerprogram instructions may also be loaded onto a computer or otherprogrammable apparatus to cause a series of operational steps to beperformed on the computer or other programmable apparatus to produce acomputer implemented process such that the instructions which execute onthe computer or other programmable apparatus provide steps forimplementing the functions specified in the flow chart block or blocks.

Accordingly, blocks of the flow charts support combinations ofstructures for performing the specified functions and combinations ofsteps for performing the specified functions. It will also be understoodthat each block of the flow charts, and combinations of blocks in theflow charts, can be implemented by special purpose hardware-basedcomputer systems which perform the specified functions or steps, orcombinations of special purpose hardware and computer instructions.

FIG. 5 illustrates a distributed network system 500 according to aspectsof the present invention. A computing device 503 is shown, connected toa network 505. Various servers are also connected to the network 505.For instance, a web server 510, a tile server 515, and a location dataserver 520 are all shown as being in communication with the network 505,although other servers (not shown) may also be connected to the network505. The computing device 503 may be any type of device configured forcomputing, such as a personal computer, a mobile phone, a personaldigital assistant, a navigation system located in a vehicle, and so on.The servers 510, 515 and 520 may each be any device capable of hostingservices over the network 505, such as a network server or a web server.The servers 510, 515, and 520 may also be capable of determining and/orobtaining some or all mapping information based on user input.Alternatively, the computing device 503 may be equipped with thecapability to determine and/or obtain travel directions. In someimplementations, the computing device and the servers (or variousportions thereof) may be co-located in one or more machines

The network 505 may be any type of distributed network, such as a localarea network, wide area network, switched telephone network, Intranet,Internet or World Wide Web network. Alternatively, the network 505 maybe a direct connection between the computing device 503 and the servers510, 515, and 520. The computing device 503, network 505 and/or servers510, 515, and 520 may be in communication via any type of wired orwireless connection. Moreover, the computing device 503, the servers510, 515, and 520, and other computing devices (not shown), and/or otherservers (not shown) in communication with the network 505 may be used toperform any or all functions described herein.

FIG. 6 is an exemplary diagram of a computing device 503, or of servers510, 515, and 520. Computing device/servers 503/510/515/520 may includea bus 600, one or more processors 605, a main memory 610, a read-onlymemory (ROM) 615, a storage device 620, one or more input devices 625,one or more output devices 630, and a communication interface 635. Bus600 may include one or more conductors that permit communication amongthe components of computing device/server 503/510/515/520.

Processor 605 may include any type of conventional processor,microprocessor, or processing logic that interprets and executesinstructions. Main memory 610 may include a random-access memory (RAM)or another type of dynamic storage device that stores information andinstructions for execution by processor 605. ROM 615 may include aconventional ROM device or another type of static storage device thatstores static information and instructions for use by processor 605.Storage device 620 may include a magnetic and/or optical recordingmedium and its corresponding drive.

Input device(s) 625 may include one or more conventional mechanisms thatpermit a user to input information to computing device/server503/510/515/520, such as a keyboard, a mouse, a pen, a stylus,handwriting recognition, voice recognition, biometric mechanisms, andthe like. Output device(s) 630 may include one or more conventionalmechanisms that output information to the user, including a display, aprinter, a speaker, and the like. Communication interface 635 mayinclude any transceiver-like mechanism that enables computingdevice/server 503/510/515/520 to communicate with other devices and/orsystems. For example, communication interface 635 may include mechanismsfor communicating with another device or system via a network, such asnetwork 505.

As will be described in detail below, computing device 503 and/orservers 510, 515, and 520, may perform operations based on softwareinstructions that may be read into memory 610 from anothercomputer-readable medium, such as data storage device 620, or fromanother device via communication interface 635. The softwareinstructions contained in memory 610 cause processor 605 to performprocesses that will be described later. Alternatively, hardwiredcircuitry may be used in place of or in combination with softwareinstructions to implement processes consistent with the presentinvention. Thus, various implementations are not limited to any specificcombination of hardware circuitry and software.

A web browser (such as web browser 300 shown in FIGS. 3 and 4)comprising a web browser user interface (such as web browser interface100 shown in FIGS. 1 and 2) may be used to display information (such astextual and graphical information) on the computing device 503. The webbrowser 300 may comprise any type of visual display capable ofdisplaying information received via the network 505 shown in FIG. 5,such as Microsoft's Internet Explorer browser, Netscape's Navigatorbrowser, Mozilla's Firefox browser, PalmSource's Web Browser, or anyother browsing or other application software capable of communicatingwith network 405. The computing device 503 may also include a browserassistant. The browser assistant may include a plug-in, an applet, adynamic link library (DLL), or a similar executable object or process.Further, the browser assistant may be a toolbar, software button, ormenu that provides an extension to the web browser 300. Alternatively,the browser assistant may be a part of the web browser 300, in whichcase the browser 300 would implement the functionality of the browserassistant.

The browser 300 and/or the browser assistant may act as an intermediarybetween the user and the computing device 503 and/or the network 505.For example, source documents or other information received from devicesconnected to the network 505 may be output to the user via the browser300. Also, both the browser 300 and the browser assistant are capable ofperforming operations on the received source documents prior tooutputting the source documents to the user. Further, the browser 300and/or the browser assistant may receive user input and transmit theinputted data to servers 505/515/520 or other devices connected to thenetwork 505.

Exemplary System Overview and User Interface

As described in more detail below, certain aspects of one embodimentassume the existence of large (e.g., on the scale of the entire UnitedStates), contiguous map raster images at each of an appropriate set ofdiscrete zoom-levels. During a one-time, off-line phase, the systemgenerates and cuts these large raster images into segments (e.g.,rectangular tiles) of a size generally an order of magnitude smallerthan the desired map view, and stores these tiles in a format supportedby web browsers in a server-side database.

As shown in the example of FIG. 7, when a web user requests a new mapview via application software 700 (such as web browser 300 shown inFIGS. 3 and 4), HTTP requests are sent to a server 710 only for thesmallest set of tiles needed in conjunction with the tiles that arealready present in the web browser (or in the web browser's cache, shownas Local Memory 705 in FIG. 7 (which, without limitation, could beimplemented as Main Memory 610, ROM 615, and/or Storage Device 620 asshown in FIG. 6) to produce the new view. The format of the responses tothese HTTP tile requests contains information in the header fields thatencourages the web browser to cache the tiles locally. By executing aset of scripts, the web browser then seamlessly assembles the combinedset of tiles into the new map view for presentation to the user. Sincethe old map view in general is still present in the browser, additionalscripts may be used to smoothly animate the transition from the old tothe new map view, either as part of a panning and/or zooming operation.Moreover, location markers and routes can be overlaid on top of thepre-rendered map tiles, for example in response to user requests fordriving directions, local search, yellow page look-ups, and the like. Inaddition, similar techniques can be used to highlight areas and streetson the map image, for example.

From the perspective of an end-user (such as a user interacting with aweb browser running on computing device 503 shown in FIG. 5), FIG. 8depicts one embodiment of a combined map request and map display page800 according to aspects of the present invention. As shown in FIG. 8,page 800 includes a map image 805, overlaid directional map controlobjects 815, overlaid zoom control objects 820, location request textentry field 825, search button 830, information window 840, locationmarker 845, location marker shadow 850, and information window shadow855. As will be described in detail later, map image 805 is actuallygenerated by aligning a tile grid relative to a clipping shape havingapproximately the same size and shape as the map image 805. The tilegrid in one embodiment comprises a number of smaller individual maptiles that are seamlessly arranged into a larger image for display.Using image overlay technologies and absolute positioning techniquesthat are well-known to those skilled in the art, directional map controlobjects 815 and zoom control objects 820 may actually be located withinmap image 805 itself, thereby increasing the area within display page800 that is available for the map image 805. In this way, an arbitrarysize for map image 805 may be implemented, which is not limited to awhole number of map tiles. Moreover, any arbitrary point may be locatedat the center of map image 805. In one embodiment, location query textentry field 825 is implemented as a single text field, such that thevarious components of the desired location to be mapped (such as itsstreet address, city, state, or zip code) do not need to be specifiedusing multiple fields. As will be discussed later, in one embodiment,FIG. 8 also includes billing point 860 at the center of the map image(although billing point 860 is typically not a visible feature on mapimage 805).

When search button 830 is selected, the desired location to be mappedthat has been entered into text entry field 825 is parsed, either at theuser's computing device or at a remote server, and map image 805 isgenerated and displayed (by means of the detailed processes that aredescribed throughout this document). The desired location that wasentered into entry field 825 may also be repeated and displayed as themap title 840, either in its original or in its parsed form. The desiredlocation to be mapped is graphically identified within map image 805 bylocation marker 845 and its shadow 850. As will be described later, byusing effects that make location markers to appear visually astwo-dimensional, and which comprise angled shadows, visual clutterwithin map image 805 is minimized, especially when multiple locationmarkers are located in close proximity to each other, and the actuallocation on the map corresponding to the location marker may be moreeasily identified as a point.

In terms of user image control functionality, directional map controlobjects 815 may be implemented as a set of arrow-labeled pan buttonsthat cause the map to pan, say, by 25% of the clipping shape size in thedirection of the arrow. These buttons could also be labeled by compassorientation, such as “west,” “north,” or “north-west.” As shown in FIG.8, zoom control objects 820 may include buttons labeled “+” and “−” thatcause the map to zoom in and out by a single level, respectively. Thesebuttons may also be labeled by the main geographic abstraction of thecorresponding zoom level, e.g., “street,” “city,” “county,” “state,”“country,” and the like. As also shown in FIG. 8, zoom control objects820 may also include a slider with a discrete position for each zoomlevel. From the user's perspective, moving the slider to a specific zoomlevel may have the same effect as selecting the corresponding zoomlevel.

As additional examples of user interface functionality provided in oneembodiment, “clicking on” or otherwise selecting a specific portion ofmap image 805 causes the selected location to pan to the center of themap image 805, while “double-clicking” or otherwise emphaticallyselecting a specific portion of map image 805 causes the selectedlocation to pan to the center of the map image 805 and the zoom level tosimultaneously increase. In another embodiment, “double-clicking” orotherwise emphatically selecting a specific portion of map image 805causes the selected location to pan to the center of the map image 805,while clicking on or otherwise selecting a location marker (either amarker within map image 805 or a marker adjacent to map image 805)causes an information window associated with the marker to open, andsubsequently clicking on or otherwise selecting any portion of the mapimage causes the information window to close. Dynamic resizing of mapsis also supported in one embodiment. For example, when a display window800 is resized, the map image 805 inside the window is re-centered (soas to preserve the location that was the center in the previous windowsize), and the map is resized (so that it shows a smaller area if thenew window is smaller, or a larger area if the new window is larger),without changing the zoom level or generally requiring there-transmission of image information to the user's web browser. In oneembodiment, the user can “grab” a corner or other portion of the mapimage 805 (e.g., by holding down a mouse button while a mouse icon ispointing to the selected corner) and “drag” it to resize the map image(e.g., by holding the mouse button down while moving the mouse to aselected location and then releasing the mouse button).

One embodiment implements mouse dragging functionality, whereby a mapview may be smoothly shifted, for example, by holding down the user'smouse button, dragging the mouse to a new location until the desired mapview is effected, and then releasing the mouse button. Moreover, mapscrolling functionality is also implemented in one embodiment, whereby amap view may be shifted (or “panned”) simply through activation of thearrow keys on a user's keyboard, or via a similar user action.

In one embodiment, entering a whole or partial postal address into textentry field 825 causes the map image 805 to pan to the correspondinglocation and zoom to a level that depends on the completeness of theaddress that was entered. For example, entering “6936 Bristol Dr.,Berkeley Calif.” pans to the corresponding location and sets the zoomlevel to be close to street level, whereas simply entering “Berkeley,Calif.” without more specific address information would pan to thecenter of the city of Berkeley and set the zoom level to city level.Moreover, location outlines are implemented in one embodiment, such thatif a user specifies a general area (e.g., a city, state, or zip code)instead of a specific address, an outline can be drawn around thegeneral area to highlight it (as illustrated, for example, by locationoutline 2810 in FIG. 28). This functionality can assist a user to gaugedistances and focus on areas of interest. Also, in one embodiment, theuser may define a set of shortcuts (such as “home,” “work,” or“grandmother's house”), which when entered or otherwise selected cause a“jump” action in the map image to the desired shortcut location (or a“zoom/pan” action if the requested location is sufficiently close to thecurrent location).

As shown in FIG. 8, one embodiment also implements “information window”functionality, whereby clicking on or otherwise selecting a locationmarker such as marker 845 opens an interactive window 840 and its shadow855 overlaid within map image 805 that contains more information aboutthe location represented by the marker.

In addition to entering a single location to be mapped into text entryfield 825, users may execute combined searches in one embodiment,whereby users may specify items to search for and locations to map allwithin a single text box (e.g., “movies in San Francisco” or “pizza nearMountain View”). Moreover, in conjunction with the location shortcutsdescribed earlier, users can give names to specific locations (e.g.,“home”, “work”) (which may or may not be associated with an address bookor similar database or utility on the user's computing device), and thenemploy the shortcut names when entering searches into text entry field825 (e.g., when searching for “bars near work”).

One embodiment also implements driving direction functionality, eitherby means of a single text entry field 825 as shown in FIG. 8, oralternatively, by means of one text entry field for the startinglocation and a second text entry field for the end location (asillustrated by text entry fields 825 and 828 shown in FIG. 27). As afurther exemplary alternative, driving direction functionality may alsobe implemented by two sets of specific text entry fields, one set forthe starting location fields (e.g., starting street address, startingcity, starting state, etc.), and a second set for the end locationfields. Regardless of the driving direction entry field interface, oneembodiment implements client-side rendering of the route information.Specifically, in one embodiment, the server transmits the turn-by-turntextual directions to the client computing device, along with the vectorinformation for the graphical depiction of the entire route.

The graphical driving directions are then rendered by the client as anoverlay on top of the previously rendered map image. In anotherembodiment, once the client receives the vector information, the clientcomputes the graphical definition of the route overlay image and thentransmits a request to the server to supply the actual overlay image.Moreover, as shown in FIG. 27, textual driving direction maneuvers 2730(e.g., “Take the Moffett Blvd. exit”) may be displayed on the web page800 near the map image 805. Clicking on or otherwise selecting one ofthe textual driving directions opens an information window pointing tothe corresponding section of the map image 805 (e.g., the freewayoff-ramp from southbound US-101 to Moffett Blvd.). As shown in FIG. 27,the information window displays a blow-up of the corresponding sectionof the map image 805.

In one embodiment, the information window additionally contains a“satellite” button or similar user interface object that, when clickedor otherwise selected, replaces the graphical blow-up of the map with acorresponding satellite photograph of the same area. The graphicaldriving directions (i.e., the traces depicting the route) can also bedisplayed as an overlay on top of the satellite picture. A “satellite”button or similar user interface object may also be included within (orassociated with) the main map image 805 such that, when clicked orotherwise selected, the “satellite” button replaces the pictorial typeof map image 805 depicted in FIG. 8 with a corresponding satellitephotograph of the same area.

Server-Side Architecture and Map Tile Generation

In one embodiment, maps are displayed by stitching together in thebrowser a set of pre-rendered “tiles” of map image. These map tiles areproduced during an off-line phase by drawing very large maps of theentire geographic area covered in each of a predetermined numberdiscrete zoom-levels (e.g., 15), then cutting those maps into tiles, andencoding the tiles into an appropriate image format (e.g., GIF). Thepre-rendered tiles are served as static images from a set of servers.For example, to cover the entire continental United States, hundreds ofmillions of tiles are required, with a total file size for the tiles inthe order of hundreds of Gigabytes of data. Instead of drawing a mapimage from the underlying data on demand, the entire map is pre-drawn insections (tiles), and the appropriate tiles are sent to the client whenthey are needed. Thus, in general, a given map tile need only betransmitted to the client once. This approach is more reliable, faster,and requires lower bandwidth than conventional systems.

Thus, in an off-line process that is transparent to the user, a set oflarge, contiguous, pre-rendered raster images of the entire area coveredby the map system are generated. One such set of raster images isprovided for each zoom-level, ranging from street to country level, forexample. Each map image 805 (as shown in FIG. 8) that is eventuallyassembled and displayed at a user's web browser matches a sub-area(typically shaped as a rectangle) of one of these large pre-determinedraster images. Alternatively, the map image boundary may be changed toappear as a different shape (e.g., a rectangle with rounded corners asshown in FIG. 8) by overlying images onto the map image boundary thatmatch or blend with the background surrounding the map image.

In one embodiment, the zoom levels are numbered 0 thru Z, where 0represents the level closest to street level, and Z the level thefurthest away from street level. An arbitrary latitude/longitude(“lat/lon”) point within the area of interest is designated and definedas the origin, or origo (for example the geographic center of thecontiguous United States). Then, at each zoom level z, the coordinatetriplet (0, 0, z) is assigned to the pixel of the z-level raster imagecontaining this origin. Using the standard computer graphics conventionthat x-axis coordinates grow left-to-right, and y-axis coordinates growup-to-down, a unique coordinate triplet (x, y, z) is assigned to eachpixel of each of the raster images.

A coordinate conversion routine, given a zoom-level z, converts alat/lon coordinate pair to the appropriate (x, y, z) pixel coordinate,and vice versa. The details of this conversion depend on the mapprojection that was used in producing the raster images in the firstinstance.

During an initial, off-line phase that need only be performed when theunderlying map information changes significantly (e.g., once every fewmonths), each of the large raster images are “cut” into rectangulartiles. As shown in FIG. 9, in one embodiment, the process of generatingand cutting the large raster images into map tiles is cooperativelyperformed by tile maker 905 in conjunction with map painter library 910,and a commercially available RME (“rich map engine”) library 915. Amongother tasks, the tile maker 905 ensures that adjacent sub-image tilesline up closely along their common border, in particular wherelabel-placement is concerned. Given map projection issues well known topersons skilled in the art, it may be necessary to divide the areacovered by the map system into smaller areas, and deal with eachseparately.

Still referring to FIG. 9, the underlying map data is stored in map datastorage area 920. In one embodiment, the stored map data comprisescommercially available NavTech data that has been compiled by Telcontar(a commercial provider of digital map and navigation information) intoRMF (Rich Map Format) files. Persons skilled in the art will recognizethat RMF is a format compact, binary format optimized for spatial queryprocessing. Among other tasks, one embodiment of the present inventiontakes advantage of this format to generate map images and create routeinformation. RMF is a spatial format that organizes data in amulti-dimension fashion, such that features near each other in realityare stored close together in the database. This means that once an itemin a spatially formatted dataset is found, other items close by can alsobe found with relative ease. Persons skilled in the art will recognizethat there are many other ways to organize the data, such assequentially or in layers. Still referring to FIG. 9, in one embodimentthe tile maker 905 communicates with the map painter library 910 torequest map data for making tiles. The map painter library 910 in turncommunicates with the commercially available RME library 915 to accessinformation from map data storage 920. Persons skilled in the art willrecognize that the RME library supports spatial queries that requestinformation involving the geographic relation of two or more items.Examples are “What map features fall within a given area?” or “What mapfeatures fall within a given area that have a priority level higher thana certain threshold?.” The result of the spatial query is transmitted tothe tile maker 905 via the map painter library 905 and is used togenerate map tiles. The resulting map tiles of the tile making processare stored in map tile storage area 900.

To re-produce any sub-area view of the large raster image as a map image805 on a user's web browser, in one embodiment browser-side scriptsrequire only the smallest set of tiles that together completely coversthe desired view. For any given implementation, the size of the tilescan be determined heuristically, given the following trade-off: (1)Larger tiles tend to increase the total size (in both pixels and bytes)of the tiles needed to produce a given view; while (2) Smaller tilestend to increase the number of separate HTTP requests needed to producea given view. In one embodiment, a tile size of 128×128 pixels is used,stored in the GIF format. Other embodiments use a tile size of 256×256pixels, stored either in the GIF, JPEG, or PNG formats. Other tile sizesand image storage formats may be used, depending on the requirements ofeach particular implementation. These tiles thus form a regular, squaregrid, and this property facilitates system implementation in oneembodiment. However, persons skilled in the art will recognize that anyother division of the large raster images into tiles of any shapes andsizes that allows for seamless assembly on the client-side may also beused to achieve the effect of the present invention.

Alternatively, rather than a database on the server side, in oneembodiment each tile may simply be stored in a separate file, accessibleusing unique URLs such as

-   -   http://<domain>/7/-18/1/-145_(—)12_(—)7.gif,        where the directory path 7/-18/1 in this example depends solely        on the tile coordinates, in this exemplary case equal to (−145,        12, 7).

For simplicity, the first tile of each zoom-level z is located such thatthe tile's upper-left pixel has coordinates (0, 0, z). This rulefacilitates assignment of a unique coordinate triplet to each tile byinteger-dividing the pixel x and y coordinates of the tile's upper-leftpixel by the width and height of the tile, respectively. Thus, a totalof three coordinate systems are utilized: lat/lon coordinates, pixel (x,y, z) coordinates and tile (x, y, z) coordinates. As persons skilled inthe art will recognize, this particular choice of coordinate systems isarbitrary, and chosen simply to aid in describing the algorithms used inone embodiment. In general, any consistent coordinate system willsuffice. In turn, each pixel belongs to a unique tile, the coordinatesof which are easily computed.

Front-End Server

In one embodiment, a front-end server (such as server 710 depicted inFIG. 7 or web server 510 in FIG. 5) responds to each query submitted bya user by returning a web page to a hidden frame that contains dataaccessed by client-side code implemented in JavaScript. Thus, thefront-end server 710/510 interacts with a JavaScript-based set ofprograms running on the user's browser to generate dynamic HTML(“DHTML”) code. Via this mechanism, user interface functionalitydescribed earlier, such as panning and zooming the map view 805 shown inFIG. 8, can be implemented within the client computing device 503without interaction with the front-end server 710/510. Instead, as shownin FIG. 5, the client computing device 503 merely has to request anddisplay tiles as needed from the tile server 520, which serves tile setsthat have been previously generated as described above with reference toFIG. 9.

The basic mode of operation of front-end server 710/510 is to provide aresponse to a user's query entered into the text entry field (such asfield 825 shown in FIG. 8) in the map display page 800. When a usersubmits a query, the client-side JavaScript code forms a HTTP requestthat contains the contents of the query as well as the current state ofthe map view and submits that information to front-end server 710/510,directing the resultant page to appear in a hidden iframe (or “virtualpage”). This mechanism allows the client to receive data required toimplement the mapping system (including various features of the mappingsystem, such as, for example, overlays for driving directions and otheritems, without having to reload the main/visible web page, but whilestill enabling the browser's history and/backward/forward buttons towork as expected, so that the user may do a local search, for example,then get directions, and click back to get back to local search results.Once the virtual page is loaded at the client, JavaScript on the mainpage may pull the data from the virtual page and adjust the main pageaccordingly, by: (1) changing the HTML title; (2) changing the searchform; (3) replacing the HTML IMG references in the tile grid with theURLs of the tiles to be displayed in the map image; (4) panning and/orzooming the map display; and/or (5) adding or replacing one or moreoverlays on the map.

In one embodiment the following types of queries are recognized andprocessed:

1) Location queries (e.g. “Berkeley”). These are queries that contain asingle geographic location. In response to such queries, the front-endserver 710/510 directs the client to pan and/or zoom the map to thatlocation and to mark the boundaries of that location on the display. Forexample, in one embodiment a “point” query (e.g., for a specificaddress, as shown in FIG. 8) results in a display that includes alocation marker for the requested location, while a “line” query (e.g.,for a specific street in a specific city, without specifying the streetnumber) results in a display where the requested line is highlighted onthe map as an overlay, and an “area” query (e.g., for a specific citysuch as “Anytown”) results in a display where the requested area ishighlighted on the map image as an overlay (as shown in FIG. 28).

2) Local search queries (e.g. “pizza”, “post office”). These are queriesthat contain a business name, category, or other set of search terms,but no geographic locations. In response to such queries, usingtechniques that are known to those skilled in the art, the front-endserver 710/510 searches for businesses matching the query within (ornear) the current map view based on the user's navigation of the map orthe positioning resulting from querying for a location, and directs theclient computing device 503 to display the results as a set of locationmarkers 845/850 on the map image 805, optionally along with a legendassociated with the map image 805 describing the search result that eachmarker symbolizes.

3) Qualified local search queries (e.g. “pizza in Palo Alto”, “singlemalt scotch near San Francisco”). These are queries that contain bothsearch terms and a geographic location. In response to such queries, thefront-end server 710/510 directs the client computing device 503 to panand/or zoom to the indicated location and to display the search resultsfound within or around that location. Alternatively, the geographicinformation contained in the query is converted to lat/lon points, alocal search is conducted with respect to this set of lat/lon points,and subsequently the zoom level is set to ensure that all of thelocations in the result of the local search are displayed on the mapimage (see FIG. 24 for a resulting display, given a search for “greatsushi in New York”).

4) Driving directions queries (e.g., “from San Francisco to New York,”“from home to work,” or “from 123 Main St. Los Angeles, Calif. to 801University Ave. Palo Alto, Calif.”). These are queries that contain twodistinct geographic locations. As described earlier, in response to suchqueries, in one embodiment front-end server 710/510 can transmit theroute information, along with textual turn-by-turn directions, to theclient, which may then display the route as a highlighted overlaid pathin the map image 805. As also described earlier, the user may interactwith these textual directions by zooming into portions of the route(e.g., by clicking on or otherwise selecting specific driving maneuvers)to obtain additional textual or graphical details.

The front end server 710/510 can be implemented as a number of differentlogical control flows which are selected based on a query classifier. Aquery classifier includes a location extractor that takes a set oftemplates defining how a query string may be broken down intoconstituent parts including search terms, geographic locationidentifiers, and literal text. For example, a template such as “{QUERY}{STANDALONE_CITY}” would match a query entered by a user simply as“pizza palo alto” and result in a search for “pizza” near the centroidof Palo Alto, Calif. The location extractor has access to a relativelylarge database consisting of a set of location names of various types,such as street names, city names, and the like.

In one embodiment, as shown in FIG. 10, the front end server 710/510also includes a geocoding/geomap server 1010 that converts anunstructured location into a structured location plus a geographicpoint/line/area that can be marked on the map image 805 of FIG. 8. As isalso shown in FIG. 10, Geomap server 1010 cooperatively communicateswith drill-down server 1015, map data storage area 920, location dataserver 1000, and local search server 1010 to process geographic featuressuch as street addresses, streets, intersections, points of interest,cities, neighborhoods, ZIP codes, counties, metropolitan areas, states,and the like (as well as their international equivalents). For pointfeatures such as street addresses, the result of the conversion is asingle (latitude, longitude) point. For linear features such as streetsand for area features such as cities, the result of the conversion iseither a polyline (e.g., for a street) or a polygon (e.g., for a city),that defines each of those features. Alternatively, the result of theconversion may simply be an axis-aligned bounding box.

As is also shown in FIG. 10, in one embodiment, the front end server710/510 also includes a local search server 1005 for finding searchresults in or around a given geographic location. For combined queriessuch as “pizza in palo alto,” the local search server 1005 may wait toreceive the results of the geocoding/geomap server 1010 beforeexecuting. For digital mapping systems, implementing a local searchscoring algorithm within local search server 1010 that has a flexibledefinition of location restriction and a notion of distance flatteningis desirable. The user should advantageously be able to search forbusinesses within the current map view that match a given set of queryterms. This requires that the local search code allow restrictions thathave the form of minimum and maximum latitude and longitude coordinates,instead of just centerpoint and radius. Some degree of distanceflattening is generally necessary. In other words, results at the exactcenter of the map display should not be scored higher than resultselsewhere in the display view. For example, searching for “pizza in paloalto” should not score two Palo Alto pizza parlors differently becauseone happens to be closer to the centroid of Palo Alto than the other.

In one embodiment, when a “driving directions” query is recognized byfront-end server 510/710, the front-end server converts the source anddestination addresses to a set of simple turn-by-turn directions, aswell as a polyline specifying the (latitude, longitude) coordinatesalong the route. The front-end server 510/710 may then transmit theturn-by-turn directions to the client computing device using XML (e.g.,in a vpage), along with a set of polylines that contains the vectorinformation along the entire route. In one embodiment, beforetransmitting the set of polylines to the client, the front-end serverreduces the total number of graphical data points that are transmittedto the client (e.g., using geometrical operations well known to personsskilled in the art to eliminate from the set of polylines any data pointthat, when eliminated, results in an error with respect to the full setof polylines no higher than a certain predetermined threshold, such asone or two pixels), and assigns each non-eliminated data point to a“group” that defines the zoom level at which the point becomes visuallyrelevant (e.g., data points in group “A” may be required to be displayedat every zoom level, while data points in group “B” are not required tobe displayed until the zoom level has increased past the zoom levelcorresponding to a city-level view or finer, etc.).

In one embodiment, initially, after a user enters a driving directionsquery, the map image 805 displays an overview of the entire selectedroute. The user may then zoom in to parts of the route to get moredetailed views.

In one embodiment, a billing mechanism is implemented for keeping trackof the number of map views requested by a user, e.g., for keeping trackof how much total map area a user has visited in relation to the mapview. Referring to FIG. 8, as mentioned earlier, a billing point 860 isdefined at the center of the map image (although billing point 860 istypically not a visible feature on map image 805). Thus, for example, ifmap image 805 comprises an area defined as 400 pixels wide and 400pixels high, other billing points are defined in the horizontal andvertical directions at intervals of 400 pixels (thereby creating abilling point grid). Thus, in one embodiment, every map view includes atleast one transaction. If a user initiates a panning operation, thebilling point grid “moves” along with the map, triggering additionalbilling transactions whenever a new billing point enters into the mapview. For example, if the user pans the map image by 200 pixels to theright, a new billing point will come into view and trigger a newtransaction. In one embodiment, a new transaction would also betriggered as a result of a zooming operation to display a previouslyunviewed map area at a given zoom level. Transactions are reported bythe client to the front-end server 710/510 in one embodiment, whichcollects the transaction information from all users and uses is forcontractual purposes with commercial providers of map information.

Client-Side Architecture and Algorithms

Embodiments of the present invention may be implemented using a widerange of technologies available in modern web browsers. A commongraphical feature of certain embodiments is the ability to assemble aset of map tiles behind a “clipping shape.” In addition, the hosttechnology at the user's computing device 503 should allow for areasonably efficient, dynamic change to the display layout. Preferably,but not necessarily, the client's web browser should perform suchdynamic changes using a double-buffered (or similar) display to avoidflickering. For example, DHTML uses a double-buffered display engine. Inone embodiment using DHTML, the browser executes script functions inresponse to events such as user input, HTTP completions and timeouts.All changes made to the web page during script execution are, at leastlogically, recorded in an off-screen buffer, which is displayed when thescript yields control back to the browser.

As described in more detail below, client-side algorithms according toone embodiment proceed in general by making a set of changes to the maptile layout, and then requesting the host system to display the newframe defined by those changes. In one embodiment, the map displayfunctionality at the client side may implemented in HTML code asfollows:

<div id=“mapView” style=“position: relative; overflow: hidden;”> <divid=“mapDiv” style=“position: absolute;”> <table id=“mapTable”><tbody><tr><td><img src=“images/bg.gif”></td> . . . </table> </div> </div>In this embodiment, JavaScript code on the site pans and zooms the mapby placing appropriate map tiles in the <img> elements of mapTable, andby moving mapDiv relative to mapView. Thus, the client-side algorithm inthis embodiment implements two primary graphical elements. The firstelement is a “clipping shape” (typically a rectangle) through which theuser will see the map image 805, and which defines the shape of theuser's map view. Solely for the purpose of explaining a client-sidealgorithm in one embodiment, an arbitrary pixel of the clipping shape isassigned as its origin (for example the upper-left pixel in the case ofa rectangular clipping shape). The second element is a grid of tileslarger than and placed behind the clipping shape, such that only thepart of the grid that intersects the clipping shape is visible to theuser. For the remainder of this discussion of one embodiment, it shallbe assumed that this grid is rectangular, and that it only changes sizeif and when the clipping shape does. Persons skilled in the art willrecognize that variations of the algorithms discussed herein exist wherethis property would not hold true.

Generally, the clipping shape remains fixed relative to the webbrowser's window 800, whereas client-side scripts according to aspectsof the present invention will move the location of the tile gridrelative to the clipping shape, in particular to pan the map image 805.FIG. 11 illustrates these two graphical elements, while FIG. 12 depictsthe result of processing the tile grid through the clipping shape fordisplay on a web page. As shown in FIG. 11, a square 5-by-5 tile gridarray 1100 comprises 25 individual tiles (each of which is defined byred boundary lines). A square clipping shape 1110 (shown as a blackrectangle) defines the subset of the tile grid that will be displayed asa map image on the client's web browser. In FIG. 12, the “clipped” tilegrid array 1200 is displayed with boundaries that are contiguous withthe boundaries of the clipping shape. As mentioned earlier, the mapimage 805 shown in FIG. 8 is also the result of a larger tile grid arraythat has been compared with a clipping shape. FIG. 13 illustrates theunderlying tile grid coordinates and clipping shape 1305 that maycorrespond with a set of displayed images, such as those shown in FIGS.11 and 12. In FIG. 13, each of the 25 tiles within 5-by-5 tile gridarray 1300 is represented by a unique set of tile coordinates.

In one embodiment, the clipping shape is a rectangle of fixed size300×300 pixels, and positioned at the center of the web page 800 asshown in FIG. 8. The clipping shape is implemented in one embodiment asa DIV element with style “overflow:hidden; position:relative” and id“mapView.” The tile grid is of fixed size 5-by-5 tiles. It isimplemented as a TABLE element with id “mapTable.” Each of mapTable's 25TD children contains a single IMG element, such that placing a tilesimply entails appropriately changing the SRC attribute of the IMGelement. The mapTable element is the child of a DIV element with id“mapDiv” and style=“position:absolute.” The POSITION styles of mapViewand mapDiv makes it possible to move the tile grid relative to theclipping shape simply by changing the LEFT and TOP styles of the mapDiv.

In general, the size of the tile grid relative to the size of theclipping shape may depend on various implementation factors describedbelow. Roughly speaking, the smallest grid of tiles that is at leasttwice the size (in both the width and height) of the clipping shape (inpixels) may be used. Again depending on implementation choices, it maybe necessary to dynamically change the size of the tile grid when theuser changes the size or shape of the clipping shape.

For the purpose of the following exemplary discussion, A and B representthe width and height, respectively, (in term of tiles) of the tile grid.Each position in the tile grid is assigned a coordinate pair (a, b) withthe upper-left position having coordinates (0, 0), and the lower-rightposition having coordinate (A-1, B-1). During calculations, referencemay be made to positions (a, b) that fall outside the tile grid, i.e.,where a<0 or A≦a, or b<0 or B<b.

In each map image produced in one embodiment, the intersection betweenthe clipping shape and the tile grid will equal the full clipping shape,such that only map tiles are exposed to the user by the clipping shape.In the remainder of this document, this fact is denominated as the“intersection condition.”

With the above assumptions and definitions in place, one may referuniquely to any map view by the pixel coordinate triplet (x, y, z) ofthe map pixel exposed at the clipping shape's origin.

Initialization and Caching

In one embodiment, assuming that the user has requested an initial mapview (x, y, z), and further assuming that the corresponding map pixel(x, y, z) belongs to tile (xx, yy, z), the client-side scripts proceedas follows. First, the tile grid is placed relative to the clippingshape in any manner that does not violate the intersection condition.Second, (a, b) is defined as the position of the tile grid nowcontaining the clipping shape origin. Third, for each position (a+a′,b+b′) in the tile grid intersecting the clipping shape, the tile (xx+a′,yy+b′, z) is placed. Fourth, and finally, the resulting frame isdisplayed.

In general, placing a tile in a tile grid position in general will causethe browser to first check if the tile is present in its cache, and, ifit is not, to issue the appropriate HTTP request for the needed tile.Depending on the particular host technology of a given implementation,this HTTP request may be performed synchronously or asynchronously.Embodiments of the present invention improve performance by encouragingweb browsers to cache individual tiles locally. Thus, when thebrowser-side scripts instruct the browser to display a particular tile,the browser will request the tile from an HTTP server only when the tileis not already present in the browser's cache. In this way, embodimentsof the present invention benefit from separate map views containingoverlapping imagery, even if those separate views belong to differentbrowser sessions. Indeed, once a user has viewed an area while on-line,the user may view that same area while off-line, so long as only tilesalready cached by the user's browser are needed.

To achieve this effect, the client-side scripts in one embodimentidentify each tile separately by a URL (“universal resource locator”)that depends only on the coordinate triplet of the tile (e.g.,http://somedomain.com/tiles?x=0&y=0&z=0). In general, web browsersmanage their caches by using an expiration time contained in the HTTPresponse containing each tile, and/or by comparing a last modified timeof the tile in the browser's cache with that of the tile on the serverside. Since the latter of these two methods requires a somewhat costlyHTTP-request even when a cached tile should be used, the HTTP servertransmitting the tiles may be configured to report a lengthy expirationperiod, determined heuristically given the following trade-off: On onehand, a longer expiration period tends to minimize the number of HTTPrequests needed for correctly cached tiles. On the other hand, a shorterexpiration period makes it faster to promulgate new tiles to the webbrowsers when the large map input rasters change (which in practicecould occur to compensate for new road construction, or to takeadvantage of an improvement to the map drawing system that produces therasters).

Alternatively, an implementation may add a version number to the tileURLs (e.g., http://www.somedomain.com/tiles?x=0&y=0&z=0&v=1.0),configure the HTTP-server transmitting the tiles to report an expirationdate as far as possible into the future, and use some other means oftransmitting a new tile version number to the browser-side scripts onlywhen new tiles needs promulgation. This alternative system minimizes theHTTP requests issued by the browser for tiles already correctly cached,while giving full control of when new tiles should be used in place ofold cached ones. This alternative, however, does tend to use moredisk-space on the browser-side, as new tiles would not replace old onesin the browser's cache. Note that embodiments of the present inventiondo not depend on the use in particular of HTTP to transport the tilesfrom a server to the web browser. Other transport protocols supported bythe browser can be used instead, such as HTTPS or FTP. As personsskilled in the art will recognize, each transport protocol may require aslightly different approach to caching tiles. Embodiments of the presentinvention may also implement heuristic algorithms, based on recent panand zoom operations, to predict which tiles are likely to be needed inthe near future, and to use idle time and/or bandwidth to transfer thosetiles into the browser's cache. As an alternative, idle time and/orbandwidth may be dedicated to updating positions in the tile grid thatare not currently visible, and/or to request tiles that would be neededif the user were to requests single-level zoom transitions.

FIG. 14 illustrates a flowchart of one embodiment for transmitting maptiles to the web browser and caching the tiles locally at the webbrowser. At step 1400 the client receives a location candidate (e.g.,the user may have entered a location to be mapped into text entry field825 shown in FIG. 8 and then selected search button 830 in FIG. 8).Next, at step 1405, the client computing device transmits the locationcandidate to a location server (e.g. location data server 1000 shown inFIG. 10, location data server 520 shown in FIG. 5, or server 710 shownin FIG. 7). The location server then parses the location candidate atstep 1410, resulting in the generation of location data. At step 1415the client receives this location data from the location server, and atstep 1420 the client uses the received location data to create a tilerequest. For each tile in the tile request, the client determineswhether the requested tile is already stored locally. Specifically, atstep 1425, the client determines whether the requested tile is alreadystored locally.

If the tile is already stored locally, at step 1435 the client retrievesthe tile from its local memory. Alternatively, if the tile is notalready stored locally, at step 1430 the client retrieves the tile froma tile server (such as tile server 515 shown in FIG. 5). At step 1440,once it has been retrieved from either local or remote tile storage, therequested tile is displayed. Next, at step 1445, the next tile requestis determined. If more tiles remain in the request (a determination thatis made at step 1450), the process loops back to step 1425, where adetermination is made as to whether the newly requested tile is alreadystored locally. Alternatively, if no more tiles remain in the request,the process ends at step 1455.

It should be noted that most target host technologies offer access toasynchronous HTTP requests. This feature allows client-side scripts toplace a tile in the tile grid during a pan transition, and then to startmoving the tile grid before the tile actually arrives, thus temporarilyexposing the wrong tile (or, alternatively, an empty space or a blanktile) to the user. In general, depending on the particular requirementsof a given implementation, such asynchronicity may be deemed preferableto the lengthy latency that might result from always waiting for all newtiles to arrive before moving the map. In some embodiments, it may bebeneficial to replace old tiles in the tile grid with a static tileunicolored with the map's background color (and presumably almost alwaysin the browser's cache) before issuing the asynchronous request.Alternatively, a more complex implementation may wait until either thearrival of all new tiles or the expiration of some short timeout period(whichever occurs first) before starting to move the map. In such animplementation, the unicolored tile would be used only in the timeoutcase.

Overlays

According to one embodiment, all additional information beyond thefundamental map image (e.g., driving routes, specific locations) can bedrawn as overlays and placed on top of a map on the client side. Thisapproach can be used for all additional information, which means thatthe server does not need to draw any maps with specific additionalinformation on demand. Overlays can be used, for example, to displaylocation markers and routes, and to highlight streets and particularareas. As persons skilled in the art will recognize, overlays may beimplemented in various ways (e.g., through images or vectors). Forexample, client-side JavaScript may place HTML elements on top of themap display. In terms of the code snippet described earlier, all overlayelements may be placed in mapDiv, such that they move automatically withthe map when mapDiv is moved. Some of these overlay elements may alreadybe in the HTML code (with style=“display: none”) when the web page isfirst loaded, while others may be added later via JavaScript code.

FIG. 15 illustrates a flowchart that may be used according to oneembodiment for displaying driving directions as an overlay onto a mapimage. At step 1500, the client receives a request for drivingdirections from a user in the manner that has already been described. Atstep 1505, the client transmits the requested travel directioninformation to a location server. At step 1510 the location serverparses the travel direction information, as described earlier inreference to the description of the functionality of the front endserver. At step 1515, the client receives textual and geographicaltravel direction data from the location server, as described earlier. Atstep 1520, the client determines the vectors required to display anoverlay driving directions route trace onto a map image. At step 1525,the client renders the fundamental map image (if this step has notalready been done) in accordance with the flowchart of FIG. 14, asdescribed earlier. In one embodiment, at step 1528, the client thenrenders the driving directions route trace as an overlay onto thefundamental map image. In another embodiment, instead of proceeding tostep 1528, at step 1530 the client requests a travel direction imageoverlay from the location server, based on the vector information thatwas calculated by the client at step 1520. In this embodiment, at step1535, the location server creates a travel direction image and transmitsit to the client. Finally, at step 1540 in this embodiment, the clientoverlays the final travel direction image onto the map image. Anexemplary displayed map image with an overlay driving directions imageis shown in FIG. 26.

In certain implementations, specific web browsers (e.g. Mozilla/Firefox)may not be capable of drawing vector graphics as described above. Insuch implementations, a resource such as geomap server 1010 shown inFIG. 10 may generate an overlay bitmap image (e.g., for a polylineassociated with a set of driving directions), and then the browser maycomposite this transparent image onto the map image. Because the browserrequests this image directly from the geomap server 1010 in thisexample, the request is via a URL instead of a protocol buffer. Thewidth and color of the line may be specified as command-line options tothe geomap server 1010.

Panning

In one embodiment, map image panning operations may be implemented asfollows. First, suppose that the user has requested a pan from one mapview (x, y, z) to a new map view (x′, y′, z) on the same zoom level, andsuppose that the pan should be animated over n frames (where n=1indicates that the switch from the old to the new view should take placein a single step, while higher values of n indicate that the switchshould be presented as a smoother, animated pan). Further, assume thatthe two map views are “close” to each other relative to the size of thetile grid, in the sense that, along both the x and y axes, the distancebetween the two views plus the size of the clipping shape is smallerthan the size of the tile grid (in pixels).

With the above assumptions and definitions in mind, the operation of‘rotation down’ of the tile grid is defined as taking the bottom row andmaking it the top row, and then placing the resulting grid such that theremaining positions retain their old location relative to the clippingshape. Likewise, ‘rotating up’ is defined as making the top row thebottom one, ‘rotating left’ as making the left column the right one, andfinally ‘rotating right’ as making the right column the left one. Theserotation operations are used in cases where moving the tile grid wouldotherwise violate the intersection condition. There are of course othermanners in which the same effect could be achieved (for example byshifting each tile in the grid one location), but above operationaldefinitions have been found to be efficient. The client-side scriptsthus proceed as follows. First, let (dx, dy)=(x, y)−(x′, y′), and let(a, b) be the position of the tile grid now containing the clippingshape origin. Second, for each position (a+a′, b+b′) that wouldintersect the clipping shape if the tile grid was moved by an offset ofi*(dx, dy)/n for any integer i between 1 and n, place the tile (xx+a′,yy+b′, z) in position ((a+a′) mod A, (b+b′) mod B). Third, if necessary,rotate the tile grid until the intersection condition would not beviolated by moving the tile grid by an offset of (dx, dy). Fourth, foreach i between 1 and n, move the tile grid by an offset of (dx, dy)/nand display the resulting frame. Depending on the host system'sefficiency, it may be necessary to pause for some time period betweenframes. Persons skilled in the art will recognize that the order of thesecond and third steps in this process may be reversed. Also, note thata slight relaxation in the second step by assuming that n equals 1 wouldresult in a near correct presentation (although some intermediary framesmay lack a few tiles when the pan is neither horizontal nor vertical).Persons skilled in the art will also recognize that the above processwill present a smooth pan along contiguous map imagery.

FIG. 16 depicts a flow chart for performing a map image panningoperating according to one embodiment. At step 1600, the client receivesa command from the user indicating a pan event (e.g., by activation of adirectional control object 815 as shown in FIG. 8). At step 1605, theclient virtually moves the clipping viewer relative to the underlyingmap tiles. Then, at step 1610, the client determines the location ofnewly needed tiles as a result of the pan operation. Once this has beendetermined, at step 1615 the client uses this location data to create atile request. Finally, at step 1525, the client obtains any requiredtiles in accordance to the process illustrated in FIG. 14 and describedearlier.

FIGS. 17 through 21 illustrate an exemplary process of panning west by ⅓of the clipping shape's width according to one embodiment. FIG. 17depicts the state of the map image and tile grid before the tiles areupdated in the second step of the process described earlier, while FIG.18 depicts the state after this updating step has been completed. FIG.19 depicts the state after one “rotate right” operation has beenperformed according to the third step described earlier, while FIG. 20depicts the state after a few frames have been displayed in the fourthstep. Finally, FIG. 21 depicts the final state after the panning processis complete.

Persons skilled in the art will recognize that a larger grid in generalallows for longer pans to be presented smoothly using the above process.In one embodiment, the implementation choice of using a grid slightlymore than twice the size of the clipping shape allows for smooth pans ofup to the size of the current map view. To perform longer pans withoutincreasing the size of the tile grid, the entire pan operation maysimply be divided into a series of smaller pan operations, although thisapproach may result in a slightly less smooth presentation.

The above exemplary panning operation algorithm updates all necessarytiles before presenting even the first frame of the animation. Thisapproach may introduce a small latency between the time that the usermakes a request and time that the map actually starts. To overcome this,an implementation may choose to divide an n-frame pan into, say, nseparate 1-frame pans. This technique alone, however, may result in aless smooth presentation, as the amount of work to produce each framemay vary significantly with the number of tiles requiring update. A moresophisticated implementation overcomes this problem by predictivelyupdating tiles needed for future frames to even out the number of tilesrequiring update among the frames.

Zooming

In one embodiment, “zooming” refers to the transition between two views(x, y, z) and (x′, y′, z′), where z≠z′, and where the lat/lon valuescorresponding to the two views are close relative to the size of theclipping rectangle. The following discussion focuses on zoom operationsthat are “vertical” around a lat/lon “anchor” in the sense that thepixel containing the anchor occupies in each of the two views the samepixel of the clipping shape. Typically, the anchor of a zoom operationmight be the center of the clipping shape, but it could also be thelat/lon of a location marker (such as marker 845 shown in FIG. 8), thelat/lon corresponding to a pixel selected by the user, or any otherlocation within a map image. It should be noted that transitions thatcombine panning with zooming operations may be combined in certainimplementations.

In general, zooming is a more expensive operation than panning in termsof tile updates, as every tile intersecting the clipping shape must beupdated. For this reason, and because a smoothly animated zoom requirescostly image scaling operations, one embodiment performs all zooming ina single frame, simply by performing the initialization steps that weredescribed earlier.

The following discussion outlines an approach to presenting a smoothlyanimated zoom operation to the user according to one embodiment, whichis feasible in certain exemplary host technologies (e.g., Flash and JavaApplets). For simplicity, assume that the scaling factor differencebetween the two zoom levels z and z′ is exactly 2, that z′=z+1, and thatit is desired to present the transition over n animation frames. In thisdiscussion, a “final frame” refers to the frame that would be producedby simply zooming in a single frame using the initialization steps thatwere described above. Further, let s (the scaling factor) equal the n'throot of 2.

With these definitions and assumptions in mind, one embodiment of azooming algorithm proceeds as follows. First, the final frame isassembled (but not displayed). Second, for i between 1 and n−1: (a) thetiles needed for the final frame are scaled by a factor of ŝ(n−i); (b)the scaled tiles are placed such that the anchor is correctly located;and (c), the resulting frame is displayed, and a pause is included ifappropriate. Third, the final frame is displayed.

Alternatively, if z′=z−1, the tiles of the current view may be scaledinstead of the tiles of the final view, as follows. First, as above, thefinal frame is assembled (but not displayed). Second, for i between 1and n−1: (a) the tiles of the current view are scaled by a factor ofŝ(i); (b) the scaled tiles are placed such that the anchor is correctlylocated; and (c), the final frame is displayed, and a pause is includedif appropriate.

Note that in the second step (part (a)) of both of the aboveimplementations, scaling is only required for those tiles that willeventually be exposed through the clipping shape after part (b) of thesecond step is performed. Note also that the first step of the secondimplementation can be deferred until the third step. In both of theseimplementations, all intermediary frames are produced using the tiles ofthe higher zoom-level, as fewer tiles are needed in higher zoom levelsto cover the same geographic area. A more involved alternativeimplementation seeks to produce some of the intermediary frames by usingtiles from the lower zoom-level, or by alpha-blending scaled tiles fromboth the current and final frames to produce a “morphing”-like effect.Also, zoom transitions across multiple zoom levels may be implemented asa series of single-level transitions.

FIG. 22 depicts an exemplary flow chart for implementing a zoomingoperation according to one embodiment. At step 2200, the client receivesa zoom action event (e.g., by activation of a zoom control object 820,as shown in FIG. 8). At step 2205, the client determines the center ofthe zoomed display. Then, at step 2210, the client uses the determinedcenter location data to create a tile request with the new zoom level.Finally, the client renders the zoomed map according to the processdescribed earlier, with reference to FIG. 14.

Sliding and Jumping

The following discussion considers transitions between map views thatare too distant for smooth zooming and panning alone. For example, acurrent map view may display a street in Berkeley, Calif., but the usermay select a navigation shortcut or request a view of a street indowntown Manhattan, N.Y. Two exemplary approaches to this situation arepresented, denominated as “sliding” and “jumping.”

In accordance with the “sliding” approach of one embodiment, client-sidescripts assemble the final view and (typically utilizing a separate tilegrid) smoothly slide it onto the current view from the direction of thenew view relative to the old view. Alternatively, in accordance with the“jumping” approach of one embodiment, client-side scripts first zoomout, then pan, and finally zoom back down the target view. Theclient-side scripts zoom out to and conduct the pan at the lowest zoomlevel that makes the pan short enough (in pixels) for the requirementsof each particular implementation. A more sophisticated embodimentconverts this “box-shaped” motion (i.e., zoom up, pan, zoom down) into asmoother, curve shaped motion. Persons skilled in the art will recognizethat the “jumping” approach requires a much greater number of tiles andmore computing resources than does the “sliding” approach.

Resizing

Depending primarily on the web site surrounding the map view, a user mayrequest that the map view change size and/or shape. Depending on animplementation's choice of how to relate the size of the tile grid tothe size of the clipping shape, this request in turn may necessitateresizing the tile grid. There are numerous possible implementations forthis operation, including but not limited to the following. Assume thatthe current view is (x, y, z), that the corresponding pixel belongs totile (xx, yy, z), and that the resizing of the clipping shape shouldtake place around its origin. Then, the first step is to resize/reshapethe clipping shape. Next, if necessary, the size of the tile grid ismoved and increased (e.g., by adding a row to the bottom and/or columnsto the right) to the smallest size necessary so as not to violate theintersection condition. Next, let (a, b) be the position of the tilegrid now containing the clipping shape origin. As the next step, foreach position (a+a′, b+b′) in the tile grid intersecting the clippingshape, place the tile (xx+a′, yy+b′, z). Next, the frame is displayed.Finally, if necessary, the size of the tile grid is increased (e.g., byadding rows to the bottom and/or columns to the right) such that thetile grid is again at least twice the size of the clipping shape. Theresizing transition can be animated using the same techniques asanimating pan transitions, as described earlier. Also, note that, ifdesired for a particular implementation, the final step of increasingthe tile grid may be combined into the initial step of moving andincreasing the size of the tile grid. Persons skilled in the art willrecognize that the origin has been chosen arbitrarily in the abovediscussion, and that one cannot count on this condition being true ingeneral. However, the steps described above may be easily adjusted bypersons skilled in the art to account for this additional complexity.

Location Markers

As mentioned earlier, location markers according to one embodiment(along with other objects, such as information windows) can be overlaidonto the map image with corresponding shadows, which makes it easier toidentify their relative locations. In one embodiment, the shadows can bedrawn to appear as if the location markers are standing vertically on amap that is tilted at a 45° angle, stretched by a factor of the squareroot of two, and projected back onto a vertical plane. Such shadows canmake location the markers appear to have been placed on the map in athree-dimensional manner, a feature that helps users to identify thelocations pointed to by the location markers in a more precise manner,and also helps to prevent multiple markers from interfering with eachother. In addition, location markers may be represented by PNG fileswith an alpha channel containing anti-aliased markers overlaid onto themap image. FIG. 23 depicts an exemplary flow chart for overlaying a setof location markers onto a map image according to one embodiment of thepresent invention. At step 2300, the client receives a request from theuser for location-based information. Then, at step 2305, the clienttransmits the request to a location server in the manner that has beendescribed previously. At step 2310, the location server parses therequest. Next, at step 2315, the client receives location-basedinformation from the location server. At step 2320, the clienttranslates this information to a set of pixel information. Then, at step2325, the client retrieves marker and shadow images (either locally orfrom the remote location server) to be overlaid or otherwise placed ontothe map image. At steps 2330 and 2335 (which can obviously be reversedif so desired for a particular implementation), the client placesshadows and markers, respectively, onto the map image (e.g., byoverlaying them onto the map image). FIG. 24 depicts an exemplary mapdisplay web page with multiple overlaid location markers (denominated as“A” through “J”), displaying the results of an exemplary request in textfield 825 for “great sushi in New York”) according to aspects of thepresent invention.

As another example of overlaid images, FIG. 27 depicts an exemplary mapdisplay web page with an overlaid driving direction route traceaccording to aspects of the present invention. FIG. 27 includes a firsttext entry field 825 for indicating the desired the start address, asecond text entry field 828 for indicating the end start address, ahighlighted overlaid route trace 2710 corresponding to the desireddriving directions, a corresponding set of textual driving directions2730, a location marker 845 and its shadow 855 indicating the end pointof the driving directions, a similar location marker and its shadow 855indicating the start point of the driving directions, and an informationwindow 2720 and its shadow 855 displaying a detailed map view 2725 for aspecific selected maneuver (e.g., “Take the Moffett Blvd.” exit”) alongthe route. Similarly, FIG. 28 depicts an exemplary map display web pagewith an overlaid area boundary trace according to aspects of the presentinvention.

FIG. 29 depicts an exemplary flow chart for overlaying a set ofinformation windows (such as information window 840 and its shadow 855shown in FIG. 8) onto a map image according to one embodiment of thepresent invention. At step 2900, the client receives a user selection oflocation information (e.g., if a user selects a driving maneuver thatwas generated as a result of a driving direction query). At step 2905,the client creates corresponding HTML code based on the locationinformation. For example, the HTML code may be created by using XSLT (acommon script language available in Internet Explorer or othercommercially available web browsers) to convert XML code containing thelocation information into HTML. The created HTML code may then beinserted into a table, such as HTML table 2605 shown in FIG. 26A. Then,at step 2910, the client obtains a set of pre-rendered pieces (e.g., afirst corner piece 2610, a second corner piece 2612, a third cornerpiece 2614, a fourth corner piece 2615, and a pointing piece 2622 asshown in FIG. 26A) for the fixed portions of the boundary of the HTMLwindow that will subsequently be overlaid onto the map image. At step2915, the client connects these pre-rendered pieces to create thenon-fixed portions of the boundaries of the information window. Forexample, the exterior boundary of the information window may bedetermined by generating a line between the pre-rendered pieces, suchas, e.g., via connected line 2620, as shown in FIG. 26A. Then, at step2920, as discussed below, the client determines and obtains a set ofpre-rendered pieces that will subsequently be overlaid onto the mapimage to generate the fixed portion of the information window shadowimage. At step 2922, as also discussed below, the client connects thepre-rendered pieces to fill in the rest of the information window shadowimage.

FIG. 26B shows an example of an information window shadow 2625 (alsoshown as element 855 in FIGS. 8 and 27) for use with an informationwindow, along with its elementary components. The shadow image 2625 maybe dynamically created such that it corresponds proportionately to thedynamic size of the information window 2600 created as described above.An exemplary method for dynamically creating a shadow image 2625 mayproceed as follows, with reference to FIG. 26B. The height of the shadowimage 2625 may be set as one-half the height of the information window2600. As shown in FIG. 26B, the size of HTML table shadow 2625 isdetermined such that it can contain the shadow at half the height,including the blurred outline of the shadow (if present). The angledvertical lines of the information window (e.g., line 2635) may becreated by skewing them at a predetermined angle, e.g., a 45-degreeangle, to match the isometric view. For example, off-set line 2635 isset at a 45-degree angle. These angled lines may be created, either atthe client or at the server, by using a clipping rectangle to displayonly the required portion of a pre-rendered angled shadow line. Theclient also determines a set of pre-rendered pieces for the corners ofthe shadow image and the pointing piece. In FIG. 26B, for example, aninformation window shadow box corner piece 2640 and an informationwindow shadow pointing piece 2645 may be obtained, either from a serveror locally. After determining the boundaries of the shadow image basedon the size of the information window 2600, and after obtaining andclipping the appropriate pre-rendered pieces, then the rest of theconnecting lines may be determined and drawn in.

The shadow image may also be filled to create a shadow-like appearance,such as shown in FIG. 26B. To further enhance the shadow-likeappearance, the portion of the shadow image closest to the bottom of theinformation window may be the darkest and/or sharpest, while graduallylightening and/or blurring the fill the farther away the portion of theshadow image is located from the bottom of the information window.

Referring back to FIG. 29, at step 2925, the client overlays the shadowonto the map image. Finally, at step 2930, the client overlays theinformation window onto the map image. As can be seen from the examplesin FIGS. 8, 26A, 26B and 27, this method produces an information windowthat, when displayed on a digital map along with its shadow, appears tobe three-dimensional in its entirety. Optionally, the three-dimensionalappearance may be enhanced by placing multiple tile windows such thatinformation windows are placed starting from North to South, such that asense of depth is also provided. Other options are available, such asplacing the information windows from East to West. This method may alsobe used when placing more than one marker on the map.

Referring to FIG. 25, a similar technique may be employed to generatethe angled shadow 2505 for a location marker 2500.

FIG. 30 depicts an exemplary flow chart for resizing a map image displaywindow according to one embodiment of the present invention. At step3000, the client receives a notification of a change in the map imagedisplay window size (e.g., as a result of a window resizing action bythe user). Then, at step 3005, the client determines the center of themap image window. Next, at step 3010, the client determines whether thewindow size has been increased. If so, at step 3025, the clientdetermines the identity of any new map tiles that may be required tofill the new additional space, and at step 3030 the client requeststhese new tiles, either from its local cache or from a remote server. Atstep 3035, the client places the new tiles in a tile table array anddisplays the new map image. Alternatively, if at step 3010 the clientdetermines that the window size has been decreased, then at step 3015the client proportionately reduces the size of the clipping shapewindow. Finally, at step 3020, the client re-centers the clipping shapewindow on the map image center.

High-Resolution Printing

Printing a map view from conventional web map sites generally producespoor output, as the map views are presented in screen resolution, whichis often an order of magnitude lower than that of modern printers. Somehost technologies, however (including DHTML as used in one embodiment),facilitate the assembly of map views using map tiles at a resolutionsuitable for printing. Thus, to achieve higher-quality hardcopies of mapimages in one embodiment, map views can be re-assembled using printresolution tiles. Because one embodiment uses HTML IMG elements to placetiles in the tile grid, two images of the same map tile, with one (e.g.,screen_tile.gif) at size 128×128 pixels, and the other (e.g.,print_tile.gif) of size 512×512 pixels may be used for display andprinting purposes, respectively. FIG. 31 depicts an exemplary set of mapimage tiles of different resolutions for high-quality printing of mapimages according to one embodiment of the present invention. Personsskilled in the art will note that the third image shown in FIG. 31appears as a high-resolution version of the first image. Using thisobservation, in response to a print request from a user, the current mapview may be re-assembled using print-resolution tiles to achieve asuperior print output.

Software and/or hardware for implementing the steps of the flowchartsdescribed and illustrated in this document may be implemented on thecomputing device 503 and/or any combination with the servers 510, 515,and 520 or other computing devices or servers that are not shown, suchas by an Internet service provider server that is connected between thecomputing device 503 and the network 505. Moreover, the blocksillustrated may be performed in different orders and are not required tobe performed in the exact sequence illustrated. Furthermore,non-dependent acts may be implemented in parallel.

It will also be apparent to one of ordinary skill in the art thataspects of embodiments, as described above, may be implemented in manydifferent forms of software, firmware, and hardware in theimplementations illustrated in the figures. The actual software code orspecialized control hardware used to implement aspects consistent withthe principles of the invention is not limiting of the invention. Thus,the operation and behavior of certain aspects of the embodiments weredescribed without reference to the specific software code—it beingunderstood that one of ordinary skill in the art would be able to designsoftware and control hardware to implement the aspects based on thedescription herein. Further, certain portions of embodiments may beimplemented as “logic” that performs one or more functions. This logicmay include hardware, such as an application specific integrated circuitor a field programmable gate array, software, or a combination ofhardware and software.

Certain exemplary embodiments have been described and shown in theaccompanying drawings. It is to be understood, however, that suchembodiments are merely illustrative and not restrictive. The disclosureshould not be limited to the specific constructions and arrangementsexplicitly disclosed because various other modifications will occur tothose ordinarily skilled in the art.

1. A method for displaying a digital map comprising: sending a locationrequest from a client-side computing device to a map tile server;receiving a set of map tiles in response to said location request;assembling said received map tiles into a tile grid; aligning said tilegrid relative to a clipping shape; and displaying the result of saidalignment as a map image.